Digital signal processing refers to the electronic processing of signals, or any application that involves rapid numeric processing. The software development for applications on digital signal processors is an iterative process. A compiler translates source code into an assembly language source code. An assembler translates the assembly language source code files into machine language object files. Source files may contain instructions, assembly directives, and macro directives. A linker combines the object files into a single executable object module or program. As the linker creates the executable module, it performs symbolic relocation and resolves external references. The linker accepts object files created by the assembler as input. The linker also accepts archive or library members and output modules created previously. The objective of this development process is to produce an executable module that may be stored and executed on a device or processor.
Debugging tools are available to test processors and the linked, executable code. Application software development requires a level of simulation, observability and controllability of the software within the hardware system being developed. Tools for debugging software in a system context include simulators and emulators.
An emulator is a software development tool that allows software under development to be executed, controlled, and viewed in a real hardware environment. An emulator may be hardware, software or both. An emulator allows a user to perform software and hardware development, and to integrate the software and hardware with the target processor.
The most desirable form of emulator allows software development to occur in the real product hardware environment. To allow this form of emulation, the target processor provides an emulation interface that accesses its internal state. An emulation interface provides control and access to every memory location and register of the target processor, and extends the target processor architecture as an attached processor. The emulator can start or stop execution of the target processor program. When the target is stopped, the emulator has the capability to load, inspect, and modify all processor registers. Program data and program memory may be upgraded or downloaded.
Increasingly, embedded systems are being built whose purpose in whole or in part involves communication. The need for communication arises either because that is the primary purpose of the product (as in wireless devices), or because the product needs to inter-operate with other units on a network (as in Internet components). In many of these cases the product design involves more than one processor. Frequently, one processor is a micro-controller and another is a digital signal processor.
In a multiprocessor system, there is one set of development tools (compiler, assembler, linker, perhaps debugger) for each kind of processor. Traditionally, there was also an emulator for each kind of processor. However, as integrated circuit technology makes it increasingly practical to put the entire system on a chip, it becomes necessary to provide debug connection to multiple processors via a single hardware debug port. With traditional emulation technologies, there were three alternatives available:    1. Use a different emulator for each kind of processor. This would necessitate connecting/disconnecting emulators to switch between processor views. Only one processor would be debugable at a time.    2. Use a single emulator with target interface software that understood a particular kind of processor. To switch to a different processor view, different target interface software must be used. Only one processor would be debug-able at a time.    3. Use a single emulator with target software built to understand the particular combination of processors in the system. In this scheme, all processors are debugable at once. However, to debug a different kind of target system (with different processor kinds), new emulation software must be built.The first two schemes are inconvenient for the user who would like to be able to debug all processors on his system at the same time. The third scheme is difficult for the emulator provider, who must produce new target interface software every time an application with a different combination of processors arises.